While software systems continue to grow in size and complexity, business demands continue to require shorter development cycles. This has led software developers to compromise on functionality, time to market, and quality of software products. Furthermore, the increased schedule pressures and limited availability of resources and skilled labor can lead to problems such as incomplete design of software products, inefficient testing, poor quality, high development and maintenance costs, and the like. This may lead to poor customer satisfaction and a loss of market share for companies developing software.
To improve product quality, many organizations devote an increasing share of their resources to testing and identifying problem areas related to software and the process of software development. Accordingly, it is not unusual to include a quality assurance team in software development projects to identify defects in the software product during and after development of a software product. By identifying and resolving defects before marketing the product to customers, software developers can assure customers of the reliability of their products, and reduce the occurrence of post-sale software fixes such as patches and upgrades which may frustrate their customers.
Software testing may involve verifying the correctness, completeness, security, quality, etc. of a product. During testing, a technical investigation may be performed by, for example, executing a program or application with the intent to find errors. If errors are found, one or more areas in the software code may be identified based on the errors. Therefore, developers may alter the code in the identified regions to obviate the error.
After a defect has been fixed, data regarding the defect, and the resolution of the defect, may be stored in a database. The defects may be classified and analyzed as a whole using, for example, Orthogonal Defect Classification (ODC) and/or a defect analysis starter/defect reduction method (DAS/DRM). ODC is a commonly used complex quality assessment schema for understanding code related defects uncovered during testing.
It is widely accepted in the testing industry that the least expensive defects to fix are those found earliest in the life cycle. However, a problem in complex system integration testing is that there may be very few comprehensive opportunities for projects to remove defects cost effectively prior to late phase testing, and by that point in the life cycle (i.e., late phase testing) defects are relatively expensive to fix. Furthermore, for many projects there are particular kinds of high impact exposures, e.g., defects in the area of security, that are critical to find and fix, but are also difficult to test.
Measuring and predicting defect related risk in a software system is a difficult problem across the testing industry. For example, there are many factors influencing the injection of defects, as well as their impact. Additionally, defect related risk changes dynamically throughout the software life cycle. Project stakeholders could make better decisions if defect related information (e.g., the number, severity, and cost of defects) could be made available to them in a timely way. However, there is no model in the industry capable of predicting the number, severity, and cost of defects.
Accordingly, there exists a need in the art to overcome the deficiencies and limitations described hereinabove.